IBIS Macromodel Task Group Meeting date: 10 November 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis * Jared James Google: * Zhiping Yang Intel: Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Todd Bermensolo Rui Yang Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that Tuesday ATM meetings do not directly conflict with most holidays this year. He asked if people wanted to cancel any and suggested attendees think about it so we can decide next week. Randy suggested we cancel the meetings the last two weeks of December. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 3rd meeting. Randy moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Walter summarized his recent email on the topic. He said the redriver flow becomes simple if the input to every model is the accumulated upstream channel information. This makes the Init flow similar to the GetWave flow. There is still at least one troublesome case. If the terminal Rx is Init-only then there are still some issues, but most things are simplified if the input to every model is its upstream IR. Fangyi asked if this included redrivers' Tx Init functions. Walter said it did. The input to a redriver Tx would be the IR output by the redriver Rx. Arpad asked if this meant the initial Tx Init would not be passed the channel IR. Walter said yes, the input to the initial Tx would just be a unit impulse response. He said it's more aligned with the way the hardware works. Fangyi noted that this is different than the flow that is currently in the specification. Walter agreed and said his proposal is to add a new optional parameter that specifies whether the input IR to the Tx is the upstream channel (unit IR for the initial Tx) or the downstream channel. If the Tx does not adapt its equalization, i.e., if it's independent of the downstream channel, you just convolve the downstream channel after the Tx instead of making it an input to the Tx. It only becomes an issue if the Tx wants to optimize itself based on the downstream channel. Walter recalled that the idea of passing the downstream channel IR to the Tx seemed like a neat idea to some people when it was first introduced in the days before we had back-channel communication (BIRD147.6, BIRD201.1). Walter said he had objected to it initially, and now we do have a history to deal with. But if we allow the option to make the input to the Tx the upstream channel, then almost all of the flow problems go away. Arpad said he understood the proposal, but he wasn't sure it made sense from a practical point of view. If the redriver Rx gives its equalized output to the redriver Tx, is there any reason for the redriver Tx to add more equalization? After all, they are on the same chip back to back. Walter said the Rx model might do CTLE, and the Tx model might add gain. Arpad observed that a redriver chip and model come from one vendor. Walter agreed the model maker could put everything in the Rx, or put it all in the Tx, or split it up as they saw fit. The important point is that the redriver Rx gets the initial Tx equalization convolved with the initial channel as an input, and its output goes to the redriver Tx. He noted that there are some subtleties and the EDA tool would have to know how to deal with the crosstalk IR terms properly. Fangyi said the important aspect of Arpad's question was that the Tx equalization, no matter how it's adjusted, is meant to compensate for downstream loss, not upstream loss. Arpad agreed and asked how the Tx would know what it wants to do to compensate for the downstream channel, unless it had back-channel communication. Walter said that before we had back-channel, it seemed like a good idea to pass the Tx the downstream channel so it could optimize itself based on the downstream channel and improve the answer. He said we now know that is not the thing to do. Often the Tx over equalizes, and the Rx undoes some of it anyway. Now that we have back-channel, there's no need for the Tx to know about the downstream at all. Once you say every model only needs to know about the upstream channel, all the flow issues go away. Arpad said that for a single-channel simulation we now have back-channel that could allow the Rx to tell the Tx what to do, so the Tx can optimize for the downstream channel. He asked if this would still be possible if there were two channels with a redriver in the middle, i.e., would we have a back-channel capable redriver Tx that is told what to do by the terminal Rx? Walter said that BIRD147.6 (time domain back-channel) and BIRD201.1 (statistical back channel) both allow for this exact scenario. The details would be defined in the protocol, but each model along the chain can write info to and read info from the file (BIRD147.6) or string pointer (BIRD201.1) to communicate with the other models. Arpad asked if Walter's new parameter that specifies whether a Tx is looking at the upstream or downstream IR would mess up the back- channel flow. Walter said this would all be captured in the protocol, e.g., the protocol would state that none of the Tx models optimize themselves, and the terminal Rx decides it all. The protocol would define it. For most protocols the terminal Rx would control everything, and everyone else would listen. One exception is DDR5, where the primary Tx does the controlling, but it has to ask the terminal Rx to report what it sees in terms of signal quality. Arpad said the other important question involves mixing and matching Init-only, GetWave-only and Dual models. He said he thought the simplest way of dealing with the issue might be to state that every model has to have an Init that returns an impulse (statistical flow), or every model has to have a GetWave (time domain flow), but the specification doesn't make that restriction. He asked if we could simply add that restriction. Walter said that if every model in the path returns an impulse, then if it doesn't have a GetWave the tool can create a proxy GetWave for it. This is especially true if the input to Init is always the upstream channel. In that case, then if a model also has GetWave the tool can use it, or if not the tool can apply the proxy GetWave using the equalization from the Init. Fangyi asked how this would work if the terminal Rx has DFE. Walter said a typical channel might have all upstream models Init-Only and the terminal Rx a Dual model. In fact, the terminal Rx is the one model that would not have to have an Init that returns an impulse. If all the upstream models have an Init, then whether they have a GetWave doesn't matter, and the terminal model can be Init-only, GetWave-only or Dual, and everything is fine. Walter said the only problem is if you have a GetWave-only model anywhere upstream and the final Rx is Init-only. That case is problematic because the tool would have to use deconvolution. Arpad asked if it would be sufficient to make a statement that this problematic case is not supported, or do we need to find a way to support it? Fangyi said the redriver flow has problems if the upstream Tx for any channel has a GetWave function and the downstream Rx is Init-only. The problem exists whether the Tx is GetWave only or Dual. Walter said anytime you have an Init- only model (that is only dependent on its upstream), then the input to that model can just be a unit IR and you get the equalization of the model back as the returned IR. Then the tool can use that to create a proxy GetWave. Fangyi said if you give the redriver Rx an ideal unit IR, then it can't optimize itself. Walter agreed that if the redriver Rx optimizes itself then we have a problem. Walter agreed that if the Tx has to have a GetWave to handle non-linear effects such as saturation, then in that case you want your Rx models to be Dual. He said he would prefer that all models were Dual, and the statistical flow gets all it can from the Init, but you need the GetWave time domain flow for non- linearities. Arpad asked how to handle this in the specification. He noted that when we started these discussions a year ago we came up with all of these problematic combinations and struggled to figure out how to support all of them. He said some of the issues remained, even with Walter's proposed new parameter, and he wondered if we should enumerate/prohibit the combinations that are problematic or try to figure out how to support all of them. Walter said we could state that if every model were Dual or Init-only, except that the final Rx could be GetWave-only, and this new parameter were set to say that they all look only at their upstream channels, then the flows are simple, and everything works. Outside of that, the user risks tool-dependent behavior and incorrect results. Fangyi said if we allow arbitrary combinations we will likely always run into trouble. Since we have to restrict certain combinations, why don't we just make it simple and require that every model is a Dual model? Then the flows are simple and they work. Walter said he totally agreed. Arpad said he was okay with this idea, but he and several others recalled that Ambrish was likely to disagree. Hansel asked if the specification would have to add anything to deal with cross- talk for the redriver flow. Walter and Fangyi said this was already handled. Fangyi noted that the Rx impulse matrix includes the IRs from all potential aggressors, and the Tx impulse matrix includes the IRs to any potential victims. PI Modeling in IBIS: Zhiping reported that he was planning to meet with TI to gauge their interest in joining the discussion. He is putting together a list for another IEEE sandpit event for Q1 and asked anyone interested in joining to contact him. - Curtis: Motion to adjourn. - Zhiping: Second. - Arpad: Thank you all for joining. AR: None. ------------- Next meeting: 17 November 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives